i/UJTJIORt Roger Knights ! DATB t 

ii • • 

SUDJECTf Tu rn- of - th e-0 entury Problem 



RK-WP' 

Aug. 25, 1985 



Here is a scenario to be. avoxdedi 



1 1 

* ■ 

1 ! 



Received 

. DEC 0 6 1999 

i » 

The 2000 phenomenon A - 

Director's Office 

In the last weeks of the year I9V9 ami in earl) 2000, bu:GBH!R27Q0 
computerized economies of ihe world all but collapsed. For bills endered 
in I W but due in 2000, overdue notices were issued, already Sin 1999. 
charging the debtor interest for some 99 years. Afler;January Jl f 2000, 
many systems failed to issue overdue notices for amounts due in 1999 but 
not yet paid. The data in many reports were printed in the incorrect 
sequence; data pertaining to the year 2000 preceded data for [the year 
|9*J9 instead of following it. Many computer rims terminated abnormally 
during this time because of overflow and similar errors. For Software 
tnrtiiitrnance personnel this was a very difficult and trying lime", during 
uhirh the time pressure under which they worked was unusually severe. 

The problems could all be attributed to the widespread use of a 
two-digit field for the year in computerised datu files. In thelalp 1970V 
the I980*s and the early I990js, programmers had made incorrect as* 
sumptions regarding the operation*! tuetnnes ot tne ^programs} and the 
data files they designed, . • 
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,It would seem desirable to add a clause that would shift the 
'effective turn of the century far enough fprward that a com- 
ppr\!son or arithmetic operation between dates in different 
centurion could never be attempted* Leife say that a pro- 
^rnrimpr codes *WD CENTUflX AT 09? in the entry for all two- 
d3::lt yeni^-fields in his program. 09 is t : en ye^rs after 99* 
Thor C Core f prior to all comparisons or arithmetxc operations 
involving; that field, it will be moved to ja hidden work area 
njt'i ten wUl be oubtfaoted; from it, & 100 (will be added if negatxve-i 
fchnn the operation will be executed. If the hidden field is 
tli^ tnrr^t of a math operation, xt wxll have ten addetf Dade to it 
(lOfJ's tnincni.nd) ^fter the operation, and then it will be moved back 

» ! to the original source field. In ef f ect> years are thus left- 
rotated by ten* temporarily* - * 
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Aft long as the years represented in a user»s. date fields 
are loss then 100 years apart, it will be possible, uf^, 
tJiio proposed clause, for all. later years i to- be effectively 
higher than all earlier years, regardless, of the. century 

they fall in. Note that if . it is desired! to allow a compar- 
ison of dotes to be accurate for the maximum range (99-yearo), 
il; ;:oulfl bo necessary to update the END CENTURA operand ev- 
ery year. This is undesirable, and could" be automated by 
allowing the operand to take the form shown herei 

ETID CENTUKY AT CURRENT—YEAR +1 
Y/Jmre CURRENT-YBAR contains the leftmost 2 dligit3 of DATE. 
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DUring any voluminous sorting operation, the 
of; this left- rotating would be very apparent j in fact, it 
wo,uld be desirable to» avoid this inefficiency wherever pos- 
sible* This means that the user will have to> determine 
thle maximum number of years his earliest year field will 
antedate his CURRENT- YEAR* and the number of ; years (max) . t 
his last field will postdate It # Say it f s five in both cases; he 
ctylpsi 

! END CENTURY AT CURRENT- YEAR * 5 WHEN CURRENT-YEAR IS 95 THRU 04 

The nf feot of this clause is. to, activate the left-rotation 
off years only in the years xx95 thru xx04. Thus 90$ of the 
time the inefficiency spoken of will be avoided. 

Let's look at a hypothetical case. The year; is 2000. The 
fields are DATE-ORDERED and WILL-BE-AVAILABLE-ON , It is a 
safe assumption that there are no- open orders mora than, five 
yeorM old, and that there are no out-of —stock situations 
ihnt will persist for more than five years, i The ?orst case 
would have a DATE-ORDERED of 95 and a WI LL-JJE-AVA I LABLE-ON 
of 0% When these are left-rotated by 6 (.2005-1999) they become 89 
and 99, T..C the vear is 1995» left-rotation ; of years 90 & 00 by 
O'i wi 13 convert them to. 89 & 99i so- they will combare as desired. 
If the yer>r is 2004, left rotation of years i99 and 09 by 10 
results in 89 & 99. Since this is the worst case^ all other 
cases are safe* | 

Wnbly most cases would have, a date-range jof less than ten 
vepro, no- that the length of time that inefficiency will have 
% he endured will be limited. For situations where the range 
off »ln tea is longer, it might be worth ^expanding the. fields to- 
fjoiir digit". (Hmmm— maybe a four-digit year field in DATE will 
be needed too? ) But shops should have the pptionj of avoiding 

■tlhis disruptive file conversion if they desire. > 
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jifc would bp desirable to. leave END CENTURY AT statements in- 
line in programs to- simplify 1 , things when 2100 rolls around. 
Jt would also be desirable to; start putting, such statements 
Unto programs well in advance of 2000, to- avert a crisis-fix 
!sUi»'Alon. down the road. However, it should be possible to. 
'avoM the inefficiency that will result from every reference 
C . date Sola causing a check of CURRENT-3CEAR. This isn't 
la serious inefficiency (unlike the one referred to above), 
Sut it seems "dumb- /offensive. Users who! want to^hould 
be nble t« code a compiler-directing statement to ignore 
' END CENTU RY clauses when compiling UNLESS i DATE > > "900000" | 
" ( rov pramnlpl . Such users would be trusting themselves to- 1 
IXo* example; . aucii ^« + n l enM( f C URRm't-YEkR checkin 

in n.i 
ke^p 

gromi 

I'm certain the ideas here can be vastly improved on. I 
just want to start the ball rolling in hopes that someone 
else will run with it. 
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One concern I have is how to> get non~ elementary date fields 
fko inherit yenr-rotatipn from their year fields, without 

having inappropriate group items inherit this characteristic 
jtoo, as v/hen the group item containing a year field is not 

h 'late field. 
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J/lnolher concern is how this will fit in with the assembly-' 

.language date routines that some shops use : for efficiency. 
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jTho bvtfcer concern would be reduced if COBOL had -intrinsic 

jdsil;n~hawUing functions to take over these tasks J Users 
♦who nhif ted over to using these functions wbuld pe working 
with a known quantity, which could be interfaced Iproperly 
jwith the mm CENTURY clause by the Committeie. 
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J On I .i~Iki».'R Lng functions were suggested in (83030) Suggestion 
iSmm \\anlv»rtt f j>. ?» #9. The advantages of using functions £ov 
ijthis task were not fully enumerated there. They includei 

i j 

|1 Creator program portability (The program is more self- 
1 sufficient.) 

Greater programmer portability (Less shop-specific stuff 

to learn*) 

Greater efficiency for most shops J 

i 

fjertn opportunity for computer crime. , (Monkeying ?;ith 
an assembly-lpnf^iage date routine, oa> invoking a 
special oppy of such a routine are hard*-to*de~ 
tect ways a criminal might increase interest pay- 
ments into his account, etc, Since such routines 
aren't standardised, detection ;Would be Harder for 
auditors. If the routine is in the language, 
monkeying will be harder & detection easier, IM 
think.) 
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Ho rc features (The CC can do a fuller job than most shops.) 



Tiw.no ndvpitta^es would apply to State-name functions too, 
(mostly. - . 
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i | Another concern ie reruns n CURRENT- YEAR might have to> be ad- 
justed to. reflect some time in. the past. Testing wbuld nec- 
essitate adjustment of CURRENT- YEAR inibo? the future* 



